home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930012.txt < prev    next >
Internet Message Format  |  1994-06-04  |  21KB
  1. Date: Tue, 12 Jan 93 04:30:10 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #12
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Tue, 12 Jan 93       Volume 93 : Issue   12
  11.  
  12. Today's Topics:
  13.                            CPU ID test code
  14.                               DPMI, etc
  15.             Ethernet card selection advice needed (2 msgs)
  16.          help AND kf5mg's 'stupid but they work for me fixes'
  17.                              Jehad, Jehad
  18.                              Linux & KA9Q
  19.                MID - Revisited, finished, moving on...
  20.                      MID dups problem - Revisited
  21.                   NOS BBS problem - Message (2 msgs)
  22.                             PMNOS - unzip
  23.                            PMNOS1D (2 msgs)
  24.                          Remote in JNOS 107b
  25.                              UNSUBSCRIBE
  26.                         Unwanted mail (2 msgs)
  27.  
  28. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  29. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  30. Problems you can't solve otherwise to brian@ucsd.edu.
  31.  
  32. Archives of past issues of the TCP-Group Digest are available
  33. (by FTP only) from UCSD.Edu in directory "mailarchives".
  34.  
  35. We trust that readers are intelligent enough to realize that all text
  36. herein consists of personal comments and does not represent the official
  37. policies or positions of any party.  Your mileage may vary.  So there.
  38. ----------------------------------------------------------------------
  39.  
  40. Date: Mon, 11 Jan 93 15:16:26 PST
  41. From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
  42. Subject: CPU ID test code
  43. To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
  44.  
  45. > Date:    Sun, 10 Jan 1993 14:13:42 -0500 (EST)
  46. > Message-Id: <930110141342.4fac@ids.net>
  47. >
  48. > This is what turned out to be what is known here as an "RTFM" problem.
  49. > Borland C offers a "#pragma startup" directive which allows a function
  50. > name to be specified that will be run ahead of main().  It should be
  51. > easy to link in my assembly language CPU type checked so that it is
  52. > called from a C language function referenced with the pragma.  The rules
  53. > for the pragma say that it has to take a void argument list and return
  54. > void, and there is no official way to get it to terminate.  However, we
  55. > can probably follow the example in C0.ASM and have our C routine call
  56. > the _exit() function if the wrong CPU is found.
  57.  
  58. Today morning I realized if startup code allows executing procedure
  59. before main and it is specified by address and flags put in some memory
  60. segment, a language should offer possibility to specify procedure to be
  61. executed and I supposed it is some #pragma directive. Your mail I read
  62. when came here saved me need to think which #pragma directive does it.
  63. However, the directive is accepted but probably ignored by TC 1.5 and
  64. 2.0 and IT PRODUCES BAD CODE for TC++ 1.01 (seems startup calls offset
  65. of DATA:_heaplen, causing crash). For BC 3.0 it works OK.
  66. Borland says priorities 0-63 are reserved, but should use just 0!
  67. I have put example program as CPUCHK1.ZIP on zfja-gate.
  68.  
  69. I'm just trying to implement another idea: modify NOS.EXE
  70. 73's, JT
  71.  
  72. ------------------------------
  73.  
  74. Date: Mon, 11 Jan 93 09:41:51 EST
  75. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  76. Subject: DPMI, etc
  77. To: jmorriso@ee.ubc.ca, tcp-group@ucsd.edu
  78.  
  79. > About the only real 286 solution might be to dredge up a copy of OS/2 1.3
  80. > and TCP/IP. Dump in lots of RAM, and then we would get pre-emptive
  81. > multitasking, threaded execution, etc. Has anyone tried this?
  82.  
  83. Funny you should mention OS/2, I just got some hate mail from Alan, must be 
  84. another Windows weenie. At any rate, I have had 4 versitcp-group@ucsd.eduns of
  85. NOS for OS/2 1.3,
  86. I believe the last release OS2NOSV4 is still at ucsd in some pertainant dir. If
  87. you have only a 286 and really want preemptive multitasking than your choices 
  88. are few.  Since IBM doesnt support 1.3 any longer neither do I. You dont need 
  89. that much memory, I was running with 4 meg just fine. If you want to dedicate 
  90. the 286 to NOS you might be better off using a JNOS for compatibility and 
  91. features. The fastest 286 I can think of was abt 12mhz, I wouldnt want to do 
  92. very much multitasking with only 12 mhz in a PM /windows environment.
  93. What I had sent out last week and it never got back here, so the i-net monster 
  94. must of eaten it is that it would seem to me the most straight-forward way
  95. to capitalize on above the line memory is to write the present device 
  96. interfaces as real live Device drivers. With the asy / ether and scc logic as
  97. device drivers one can tell DOS to load them high thus freeing a substancial 
  98. amt of memory below the line.  The effort required to do that would be minor 
  99. compared to the effort to use DPMI throughout NOS. Walt
  100.  
  101. ------------------------------
  102.  
  103. Date: Mon, 11 Jan 93 18:58:19 PST
  104. From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
  105. Subject: Ethernet card selection advice needed
  106. To: crompton@NADC.NAVY.MIL (D. Crompton)
  107.  
  108. Hello, Doug
  109. Our institute needs buy several new E. cards in nearest future.
  110. Till now we are using Gateway's G/Ethernet 8, G/Ethernet 16 and
  111. 3Com 3C503 (8 bit) cards. Most important things for us are:
  112. - high transfer speed: we found it depends on card memory size, the
  113.   few kB on 3C503 is insufficient, card should be rather 16-bit.
  114.   G/Ethernet 16 gives 250kB/s
  115. - low price, if possible
  116. - packet driver available
  117. - thin (50 Ohm RG-58 coaxial) cable interface
  118.  
  119. Few weeks ago (15 Dec) Doug Crompton wrote about 3Com's 16-bit board
  120. for $135, later (18 Dec): it is 3com Etherlink III, 'around $125',
  121. Gateway sells it for $105; does anyone have experience with it
  122. (transfer speed, how much on-board memory, reliability) ?
  123. Is any 8-bit card for small price available ? (we have few old XT-s
  124. and will probably need one or two e. cards for them).
  125.  
  126. Thanks for any info and 73's, JT
  127.  
  128. ------------------------------
  129.  
  130. Date: Mon, 11 Jan 93 13:55:34 EST
  131. From: crompton@NADC.NAVY.MIL (D. Crompton)
  132. Subject: Ethernet card selection advice needed
  133. To: JT@zfja-gate.fuw.edu.pl, crompton@NADC.NAVY.MIL
  134.  
  135. The etherlink III is around $125. It is ADVERTISED to be fast - faster
  136. than any previous 16 bit card. The next Clarkson release WILL support it.
  137.  
  138. Sounds like a winner to me - but I have no actual experience with it!
  139.  
  140. Doug
  141.  
  142. ------------------------------
  143.  
  144. Date: Mon, 11 Jan 93 14:09:16 EST
  145. From: crompton@NADC.NAVY.MIL (D. Crompton)
  146. Subject: help AND kf5mg's 'stupid but they work for me fixes'
  147. To: TCP-Group@UCSD.Edu, kf5mg@vnet.ibm.com
  148.  
  149. Thanks Jack,
  150.  
  151.    The lines -
  152.  
  153.        if(strlen(cp) <= OBLEN )
  154.               strcpy(origbbs,cp);
  155.  
  156. Shouldn't it be '<' rather than '<='  - strlen does not count terminating
  157. null, strcpy copies it. origbbs is defined as origbbs[OBLEN]. So if cp's
  158. len really is OBLEN then origbbs will overwrite origbbs by 1 character.
  159. Either delete the '=' or make origbbs[OBLEN+1];  as I see it????
  160.  
  161. This is also true for ODLEN and origdate.  
  162.  
  163. The length will probably never be the max by this is inviting a problem.
  164.  
  165. Doug
  166.  
  167. ------------------------------
  168.  
  169. Date: Mon, 11 Jan 93 10:03:13 EST
  170. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  171. Subject: Jehad, Jehad
  172. To: tcp-group@ucsd.edu
  173.  
  174. >       For better or for worse this computer uses a intel 386 cpu that
  175. > is interupt driven. There is no magic way to do things any better than
  176. > windows does to do what it does. Period.
  177. >
  178. > 73, karl k5di@k5di
  179.  
  180. Guys...Guys...
  181. Boy I sure hope I didnt inadvertantly start another Jehad, Has it been 6 months
  182. already??
  183. There is no reason for people to get into a lather because OS/2 is popular, 
  184. trust me, Bill Gates sleeps just fine at night and so should we all. Linix and 
  185. other real operating systems are out there and garner a certain amt of 
  186. popularity. Windows is not a real operating system, its an operating 
  187. environment. WIndows does not multitask, the i386 supports virtual 8086 "boxes"
  188. which look like multiple xt's running in one machine. That having been said, 
  189. Windows is somewhat popular as well. "Cant we all just get along" (Rodney King)
  190. Walt
  191.  
  192. ------------------------------
  193.  
  194. Date: Tue, 12 Jan 93 09:23:07 GMT
  195. From: Alan Cox <iiitac@pyr.swan.ac.uk>
  196. Subject: Linux & KA9Q
  197. To: tcp-group@ucsd.edu
  198.  
  199. A word of warning: 
  200.  The standard KA9Q distributed for Linux is meant for people using
  201. SLIP and terminal servers (mainly from before kernel slip appeared). It
  202. crashes quite easily, especially the mailbox and has bugs in the mulport
  203. repeater code.
  204.  
  205.  Last time I tried it wampes was 'getting there', and was very much
  206. a 'my god it works' version still needing all the tidying up doing. I've
  207. not seen the current version but people say its quite neat and stable.
  208.  
  209.  There's also my much hacked Linux KA9Q Net which has other oddities
  210. added to it but isn't very distributable yet that gives you things like
  211. AX.25 logins and bulletins forwarded to be read with trn.
  212.  
  213.  
  214. Linux has proved stable although 20Mb is a more realistic minimum disk
  215. space usage for a basic system. For anyone doing any compiling or other
  216. work I nornmally reckon on 40Mb for Linux 60-70Mb for 386BSD. I've built
  217. Linux for a 1Mb machine successfully (forget X, emacs or gcc tho), and
  218. in 5Mb or so you can build a minimal dedicated KA9Q system. The trouble is
  219. without a NOS port or further work we don't yet have the software to make
  220. full use of this 8-)
  221.  
  222. Alan
  223.  
  224. ------------------------------
  225.  
  226. Date: 11 Jan 1993 22:59:11 -0500 (EST)
  227. From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
  228. Subject: MID - Revisited, finished, moving on...
  229. To: johan@ECE.ORST.EDU
  230.  
  231. [Originally posted 01/10/93.... don't ask me where it went!]
  232.  
  233. Here is the "absolute" fix to the MID problem. These few lines make a brand
  234. new MID for each message (after the first) generated from an incoming message.
  235. This works equally well with CC's, aliases, etc. The first message in a list
  236. retains the original MID, all others get new numbers.
  237.  
  238. Ignore previous hack and apply this fix.
  239.  
  240. All changes are in SMTPSERV.C. The line numbers given are for WG7J107b.
  241.  
  242. insert lines with '>>', change lines with "**"
  243.  
  244.  
  245.  
  246. smtpserv.c at line 493
  247.         extern int Smtpquiet;
  248. >>        int index;
  249.  
  250.         if ((Smtpmode & QUEUE) != 0)
  251.  
  252.  
  253. smtpserv.c at line 528
  254. #endif
  255.  
  256. >>        index = 0;
  257. **        for(ap = tolist;ap != NULLLIST;ap = ap->next, index++){
  258.  
  259.  
  260. smtpserv.c at line 584
  261.                                         }
  262. >>                                        if (index && htype(buf) == MSGID)        {
  263. >>                                                fprintf (fp, "%s<%ld@%s>\n",Hdrs[MSGID],get_msgid(),Hostname);
  264. >>                                        } else
  265.                                                 fputs(buf,fp);
  266.  
  267.  
  268.  
  269. 73 from Brian A. Lantz      KO4KS@KO4KS.#TPAFL.FL.USA.NA    3100813105
  270.                   Internet: brianlantz@delphi.com
  271.                    Amprnet: ko4ks@ko4ks.ampr.org         [44.98.0.167]
  272.  
  273. ------------------------------
  274.  
  275. Date: Mon, 11 Jan 93 10:27:20 HST
  276. From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
  277. Subject: MID dups problem - Revisited
  278. To: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
  279.  
  280. > 1. You're preaching to the choir! That's why we are using NOS and not a
  281. >    "regular" BBS. It IS NOT a problem sending to standard BBSs, since NOS
  282. >    truncates the BID/MID to 13 characters if it is larger.
  283.  
  284. It IS a problem.  Let's take a simple example.  Suppose you have two
  285. public message areas on a NOS system called 'wanted' and 'sale'.
  286. These message areas are forwarded to other BBSs.  Send a message via
  287. SMTP to 'wanted' from one of many systems that use long MIDs.  Now send a
  288. second message to 'sale' from the same system.  Chances are that the
  289. first 13 bytes of both MIDs are identical and most mailers don't allow
  290. the user to assign the MID.  Only the first message will be forwarded
  291. beyond the NOS system, the other will be rejected because the
  292. receiving BBS thinks it's a dupe.
  293.  
  294. > 2. Whose idea? Don't ask me, I just try to make TNOS co-exist with the
  295. >    "standard".
  296.  
  297. The BBS 'standard' is the one that needs fixing, not NOS.
  298.  
  299. > 3. We need to generate a new MID because NOS handles aliases by using the
  300. >    same internal MID number for all messages from a common base message.
  301. >    Thus the problem that OTHERS reported. I simply gave you a way around it.
  302. > 
  303. > 4. You STILL have the option of IGNORING the fix, and living with the
  304. >    problem! No skin off my back ;-)
  305. > 
  306. > All I know is that the fix WORKS! Until something better comes along, feel
  307. > free to use it or ignore it!
  308.  
  309. You're only trading one problem for another.
  310.  
  311. Tony
  312.  
  313. ------------------------------
  314.  
  315. Date: Mon, 11 Jan 93 09:35:01 EST
  316. From: crompton@NADC.NAVY.MIL (D. Crompton)
  317. Subject: NOS BBS problem - Message
  318. To: johan@ece.orst.edu
  319.  
  320. Here is the complete message that totally bombs NOS's BBS. It is
  321. consistent! After all of the R: lines are received and just as
  322. the subject and message ID comes in it locks the system with an
  323. 'invalid pointer' It requires a hard reset.
  324.  
  325. After the BBS that was sending me this deleted it from my queue
  326. 10 messages came im without a hitch. So something in the BBS is
  327. not accepting something in this message - possible R line filtering?
  328. This is 1.07b code - also 1.06 code WG7J.
  329.  
  330. Message follows - comments are from the BBS op.
  331.             
  332. Hi Doug,
  333. Here is the only bulletin on my system with "earth" in the title.
  334.  
  335. 28698 BN  1325 ALL    W3QNS  AMSAT    1 930109 1540 EARTHWINDS-BUL
  336. R:930109/1533z 461@N3ACL.#EPA.PA.USA.NA  Eagleville Z:19408
  337. R:930109/1406z 393@N3ET.PA.USA [Allentown] Z:18103 $:48_UO22
  338. R:930109/1014z 16212@K3RLI.#EPA.PA.USA.NA
  339. R:930109/0954z 38255@NR3U.PA.USA.NA
  340. R:930109/0821z 7552@W3AVK.#EPA.PA.USA.NA
  341. R:930109/0656Z @:WA3WPS.#WPA.PA.USA.NA [EMPORIUM,PA] FBB5.14d #:4160
  342. R:930109/0703Z @:K3MD.#WPA.PA.USA.NA [DuBois, PA] FBB5.14 #:18525
  343. R:930109/0254Z @:W3YA.PA.USA.NOAM [State College] #:29685 $:48_UO22
  344. R:930109/0239z @:W3KDC.MD.USA.NOAM Cresaptown #:1847 $:48_UO22
  345. R:920108/1105Z @:N4YRZ.VA.USA.NA [Moscow Va,] - FBB5.14d #:16537
  346. R:930104/0722Z @:N4ZKF.VA.USA.NA 48_UO22 #:20137
  347. R:930103/2008Z @:KC7Y.AZ.USA.NA [Mesa,Az TELINK] FBB5.14d #:38182 Z:85204
  348. R:930103/1210Z @:N7MRP.AZ.USA.NA [ FBB-TELINK - Phx,Az ] #:42885 Z:85016
  349. R:930103/0727Z @:VE4KV.#WPG.MB.CAN.NA [Winnipeg] FBB5.14g #:53518
  350. R:1230/1058 @: #:48 Z:00000
  351. Subject: EARTHWINDS LAUNCH
  352. Message-Id: <921228181039_70304.326_DHP47-1@CompuServe.COM>
  353.  
  354. The globe circling EARTHWINDS balloon is again ready for launch with
  355. the new anchor balloon on site at Reno, NV. They have decided not to
  356. house the anchor balloon in a new inflatable dome. Launch is currently
  357. on hold due only to weather conditions locally. The weather may be more
  358. cooperative this weekend or perhaps as early as Friday. Stay tuned!
  359. Rich, n8iwj@amsat.org
  360.  
  361. **********************************************************************
  362. Possibly the initial R: line is the problem.  There is no call after the @:
  363. It's been a while but I think my code handles that case.  If NOS does
  364. anything with the Message-Id: field, it is awfully long.
  365.  
  366. The bulletin is no longer queued to you.
  367.  
  368. 73, John
  369. ***********************************************************************
  370. Doug
  371.  
  372. ------------------------------
  373.  
  374. Date: Mon, 11 Jan 93 11:07:14 HST
  375. From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
  376. Subject: NOS BBS problem - Message
  377. To: crompton@NADC.NAVY.MIL (D. Crompton)
  378.  
  379. If you turn 'bulletin date on' for that earthwinds message, I think NOS might
  380. accept the message.  However, it will generate a bad SMTP Date header. 
  381. That's what happened here when the thing came in from our satellite gateway.
  382.  
  383. Tony
  384.  
  385. ------------------------------
  386.  
  387. Date: Mon, 11 Jan 93 14:30:06 EST
  388. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  389. Subject: PMNOS - unzip
  390. To: tcp-group@ucsd.edu
  391.  
  392. For those that maybe grabbed the new PMNOS1D but discovered they didnt have the
  393. proper unzip, the OS/2 32 bit GNU unzip is available with the PMNOS1D?.zip 
  394. files at giskard.uthscsa.edu. Remember folks, Fri is the last day these files 
  395. will be available at giskard.uthscsa.edu, its easy to locate now, at ucsd it 
  396. may move around and I wont know where it is. Anyways, thanks Jack for providing
  397. the unzip util. Also, for people experiencing problems with the Font Mgr, its 
  398. strange, some people are having major problems with it and for others it runs 
  399. flawlessly. I, personnally, only have problems with it occationally but it 
  400. works ok after a failure.  Walt
  401.  
  402. ------------------------------
  403.  
  404. Date: Mon, 11 Jan 93 07:53:28 EST
  405. From: "Jon Maguire maguire@sppvm1.vnet.ibm.com" <MAGUIRE@SPPVM1.VNET.IBM.COM>
  406. Subject: PMNOS1D
  407. To: TCP-group@UCSD.edu
  408.  
  409. Where is the aforementioned? It's not at ucsd.edu incoming and I can't
  410. get to wg7j. I'd sure like to get a copy.
  411.  
  412. -----------
  413. Jon Maguire  N1CQE/4  |    ibm-vm: maguire@sppvm1 usib2tfc@ibmmail
  414. Advantis              |    Packet: N1CQE@KC4LDT.#CLWFL.FL.USA.NA
  415. Dept 8QD / Bldg PAV   |    voice: t/l:438-3038 external:(813)-878-3038
  416. 3105 W. M.L.King Blvd.|    fax  : t/l:438-3922 external:(813)-878-3922
  417. Tampa, FL 33607       |    AMSAT #21847 TAPR #2916 TPALAN BARS
  418.                       |    Internet: maguire@sppvm1.vnet.ibm.com
  419.                       |    IP 44.98.0.136 N1CQE-7.ampr.org
  420.  
  421. ------------------------------
  422.  
  423. Date: Tue, 12 Jan 93 09:31:24 GMT
  424. From: Alan Cox <iiitac@pyr.swan.ac.uk>
  425. Subject: PMNOS1D
  426. To: tcp-group@ucsd.edu
  427.  
  428. For UK people I've uploaded PMNOS1D and PKUNZIP onto sunacm.swan.ac.uk also
  429.  
  430. Alan
  431.  
  432. ------------------------------
  433.  
  434. Date: Mon, 11 Jan 93 9:06:19 EST
  435. From: John Ackermann   AG9V <John.Ackermann@DaytonOH.NCR.COM>
  436. Subject: Remote in JNOS 107b
  437. To: A.D.S.Benham@bnr.co.uk
  438.  
  439. You (A.D.S.Benham@bnr.co.uk) write:
  440. > 
  441. > I spent the weekend compiling 1.07b of JNOS to replace my current NOS (my own
  442. > compile of JNOS 1.01).
  443. > I use Borland C++ v3.0, compiling with 80186 instructions.
  444. > 
  445. > Everything seemed to work fine, except for the "remote" command.
  446. > 
  447. > Trying "remote g8fsl kick" gives the error "Unknown command g8fsl".
  448. > But 'g8fsl' is supposed to be the host, not the command!
  449. > Having checked that the command syntax hadn't changed between JNOS versions,
  450. > I checked the 1.01 and 1.07 sources in the appropriate areas - identical!
  451.  
  452. I saw this problem with, I think, v1.05.  It seems to be fixed in the
  453. 1.07 I'm running.
  454.  
  455. BUT... after much frustration, I finally came to the realization:
  456. BC++3.0 WILL NOT reliably compile JNOS.  None of the executables I
  457. created of any version (well, at least 1.04 and up) would run for more
  458. than a few hours without a hard crash.
  459.  
  460. I broke down and upgraded to 3.1 and my most recent compile of 1.07b has
  461. been up for 4 days with no problems and lots of coreleft.
  462.  
  463. I don't know what the problem with 3.0 is, but 3.1 solves it.
  464.  
  465. John
  466.  
  467. ------------------------------
  468.  
  469. Date: Fri, 8 Jan 93 9:45:44 CST
  470. From: Douglas Drury <drury@STEPSUN.ARMY.MIL>
  471. Subject: UNSUBSCRIBE
  472. To: tcp-group@UCSD.EDU
  473.  
  474. UNSUBSCRIBE
  475.  
  476. ------------------------------
  477.  
  478. Date: Mon, 11 Jan 1993 10:13:50 -0600
  479. From: miltonm@inetnode.austin.ibm.com (Milton Miller)
  480. Subject: Unwanted mail
  481. To: andy@mimuw.edu.pl
  482.  
  483. Although it doesn't solve the accepting mail to the user,
  484. you could use a rewrite file or alias to change sp5wca@sp5wca to andy@sp5wca
  485. and the rewrite file to change all unknown users to a single mail file.
  486.  
  487. milton
  488.  
  489. PS: In the AMPR community, not everyone will know your name but will know
  490. your call by seeing you on the air, so I like to see call@call.ampr.org
  491. be received by someone.
  492.  
  493. ------------------------------
  494.  
  495. Date: Mon, 11 Jan 1993 19:18:19 -0100 (GMT-1:00)
  496. From: andy@mimuw.edu.pl (Andrzej K. Brandt)
  497. Subject: Unwanted mail
  498. To: miltonm@inetnode.austin.ibm.com (Milton Miller)
  499.  
  500. Milton Miller wrote:
  501.  
  502. >PS: In the AMPR community, not everyone will know your name but will know
  503. >your call by seeing you on the air, so I like to see call@call.ampr.org
  504. >be received by someone.
  505.  
  506. Probably you are right, but mail to unknown users should be rejected, so the
  507. sender would know that address he has is wrong. Currently such mail may simply
  508. wanish without any trace.
  509.  
  510. And I really don't like mail adressed as call@call.ampr.org... (But that's my
  511. personal opinion only)
  512.  
  513. -- 
  514.  
  515.  
  516.                                73 de Andy SP5WCA
  517.  
  518.  
  519. /-------------------+--------+-------------------+-------------------------\
  520. I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I 
  521. \-------------------+--------+-------------------+-------------------------/
  522.  
  523. ------------------------------
  524.  
  525. End of TCP-Group Digest V93 #12
  526. ******************************
  527. ******************************
  528.